COMMENT ⊗   VALID 00011 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	(Review) Proposal  11-Jan-82
C00009 00003		<revised form - never sent>
C00021 00004		<con't>
C00024 00005			<Overview of Thesis Proposal>
C00056 00006		Responses to Summary
C00059 00007	Etiology
C00060 00008	Rules
C00062 00009	Types of facts, used when describing an object
C00065 00010	Consider how analogies might be used by people wrt computer programs.
C00069 00011	∂TO tw 12:01 14-Sept-82
C00072 ENDMK
C⊗;
(Review) Proposal  11-Jan-82
∂TO csd.lenat@score 17:41 11-Jan-82
	What is this document?
I am currently searching (?floundering?) for a precise thesis topic,
rather that doing any "real" research.
The ideas now considered are very rough and preliminary -- most are
(at best) but first passes, needing much refining.
Hence, this description will NOT be
along the lines of Roget paper which Jim submitted;
not only would this be very difficult to produce,
but I can't imagine how such contorted answers would be useful.
In leiu of that, 
below are a list of (hopefully) relevant questions and their answers.

	Who am I?
Russell Greiner
5th year Grad student

	What am I doing?
I am just beginning work on an application program 
which will allow domain experts to use analogies when enterring
domain knowledge into a growing expert system.

	Why is this is useful to HPP?
Most HPPer agree that knowledge acquisition is the current main problem facing
expert systems today.
Analogy is consider one strong method of solving this problem -- it would
allow the expert to communicate with the program in a natural manner; one
which saves him much of the drudgery of filling in "obvious" details.

	What will the program (eventually) do?
Concocted scenario: An expert quickly teaches Mycin about a new class of
organism, X, by stating that X is just like streptococis, except that ...
The "analogizing" program now examing Mycin's KB of rules, and
proposes new rules to cover this X case, each generated from an existing rule, R,
using a proportional analogy
	Streptococis:X :: R:<the new rule>.

	Why am I doing this?
First, I believe a successful analogizing program will have a major impact
throughout AI.  
The scenario shown above indicates how useful it is for building and
expanding an expert systems;  mutatis mutandis it could be used in
other AI "learning" tasks as well.
I also feel this system may provide the groundwork for other analogy-related tasks:
using analogies to teach or explain a concept new to the student 
(to TEACH about X, describe how it is similar to streptococis, ...), 
and for predictions and conjectures 
-- knowing that streptococis did this, expect X may do likewise
(or else that this X will have a similar effect - where the nature of the
similarity was determined from X's likeness to streptococis).

The second reason is more personal:  I've fascinated by our human ability
to generate and understand analogies.
This seems a very fundamental and immensely powerful tool --
a capability which I believe any intelligent entity must have,
both to reason effectively and to communicate efficiently.
I'm excited at the prospect of working in this area.

	How I intend to do it?
My research programme begins with a massive "knowledge acquisition" phase --
both from advisors and the available literature.
Finding input from the former sparse (though quite useful when transmitted),
I've spent the last month or two reading what I can find on analogy/metaphor,
from diverse fields - philosophy, psychology, AI (and here in learning and
more directly titled analogy papers).
In addition, I've been working through some dry-lab examples, and assembling
(and refining) a few proto-papers, including a thesis proposal to be.

	How and where will the program fit into HPP?
Programs: Perhaps it will eventually be plugged into Eurisko; and/or written up
as a module which an MRS user can load in.
Personnel:
Perhaps TGD and/or MRG will need what this program provides for their respective
tasks.  I feel a close collaboration would be profitable for me, and suspect
they might gain as well.
(We certainly should, in any case, avoid stepping on each other's toes.)

	What do I need?
Better guidance -- I've found the faculty all but unapproachable.   I will step
up my harrassment.

A few crisp, solid examples -- despite the HPP gospel quoted above, nobody
seems able to remember a single example of when they could have used a program
such as the one described above.
	<revised form - never sent>
Description:
(What am I doing?)

This research effort is examining the role analogy can play in the 
Knowledge Acquisition process.
The current focus is on an "analogy-understanding" module,
which allows a domain expert to define a new part of the domain
as being similar to some known part.

As a simple example,
consider teaching an immature (editor) expert system the various EMACS commands.
An obvious instruction would be
"word commands are just like character commands,
EXCEPT word commands use Meta rather than Control".
This analogy-understanding module will be responsible to updating the
knowledge base to include these new command,
as well as asking for any additional needed information.
Notice the (human) instructor is generating the analogy,
not this module.

There are two other types of tasks under consideration.
The first is teaching that editor Expert System a second editor --
this involves describing that second editor (say E) in terms of
the already known editor, say EMACS.
Again the module would be responsible (only) for using the editor-to-editor
analogies supplied by the expert,
not generating them.
A second, more ambitious task would use known facts, and observed analogies,
to generate new plausible connections.
This analogy-for-learning program might notice the C-x to M-x relation,
as manifest in the C-F/M-F, ... commands.  
On seeing a C-T command,
it might guess a M-T command exists, and reason (correctly) it transposes words.

(Why this particular task?)

The topic "Analogy" encompasses a large number of diverse ideas.
If there is any coherent theme which permeates these different perspective,
it is that analogy is a (?the?) non-decomposition way of claiming that two
things are similar.
Understanding an analogy seems more basic a process than generating an analogy --
in that any generator must be able to verify that the analogy is (potentially)
apt.  The setting of using a small, local analogy -- which permits a foreign
term to quickly "absorb" many (but not all, of course) of the details of a
familiar thing; seems the basic case of understanding an analogy.
(This is to be contrasted with the more general analogies,
which compare elaborate structures (e.g. electrical curcuits with water
flow systems.  These larger systems seem composed of many smaller mappings,
systematically arranged.)
Within exegesis, there is still considerable breadth.  I choose the KA task
because it is so readily verified -- the resultant expert system either uses
the newly acquired fact, or it doesn't.  
(Yes, there is still the issue of cheating:
did it learn this new fact in a correct (ie general) way?)
Hence this particular research activity.

Motivation:
(Why do I think it will work?)

This research is based on the observation that it is much easier to teach 
someone a second domain than it was to teach him the first;
especially when those two domain are similar.
Basically, that first domain (or part of the domain) will provide a
rough orgranization in which to store the new facts,
plus a host of familiar well-understood facts against which to match
the new terms.
This should be true for expert systems as well --
that incorporating additional facts should be faster and easier if
one already has a corpus of core facts, and a basic structure of
the domain.

(Why am I doing it?)

It is widely accepted that a (?the?) major problem in Expert Systems
is the Knowledge Acquisition bottleneck.
This programme is directly addressing this issue.
The tasks mentioned above show two ways
that analogy may be used by an expert system to acquire "expertise":
(1) by providing a natural language the domain expert can use
to efficiently and rapidly communicate pertanent facts,
and (2) by suggesting plausible new rules and facts, based on existing facts,
and prior analogical connections.

This analogizing capability seems most appropriate, and profitable,
for the final stage of Knowledge Acquisition (using JSB's three stages).
By this time a rough skeleton of the domain has been generated,
and many domain particulars have been enterred.
Fleshing out this structure requires many "Copy and Edit" steps.
At the very least this program should eliminate this tedious process --
or at least reduce the number of such modifications, and simplify that modifying
process.

(Why do I think it will work?)

While there are a number of analogizing programs, I know of no other
task

Research programme:
(How am I doing it?)

I am presently in a knowledge acquisition phase of this work --
trying to obtain the needed knowledge by a combination of reading,
writing and introspection.
(Following the learn by example approach I advocated above,)
I am generating a (dry-lab) scenario,
to demonstrate how this analogy-understanding program should behave.
This will be a living document -- which will be updated to reflect the
implementation (and my current thoughts) as necessary.

This emerging KA program will attempt to learn additional EMACS commands,
based on old ones.
While this task seems rather simple,
it has already forced me to examine a number of issues. 
(Many are listed in the [Intellectual Difficulties] section.)
Eventually I would like to scale up to more complex (seeming) tasks mentioned
above, staying within the same editor domain 
After that, I hope to address a less artificial, artifactual domain -- such as
molecular genetics or medical diagnosis.
(Note in both secondary tasks,
I am assuming that this initial body of "analogy" facts
(together with my preliminary organization of analogy,)
will provide both the framework I need to flesh-out
understanding of analogy, as well as an good starting set of potential analogues.)

For perspective on this task of analogy,
as well as to help me formulate my own ideas,
I am also working on a brief paper on "naive analogy".
This will record various thoughts on this topic -- both mine and others.
It will list many of the different senses of analogy found in the literature,
(based on task performed, as well as underlying theory,)
together with a set of "dimensions" used in these descriptions.

Tactics:
(How am I going about coding this up?)

<<Nothing yet>>

Milestones:
(Where am I, and when will I be where?)

While I am not ready to be tied to particular absolute times for the following,
below is my suggested relative completion dates.

Finish thesis proposal, including the desired scenario
	Current status: Ok - needs to integrate the scenario
Finish writing, and circulate, a draft of NaiveAnalogy paper
Begin coding the KA system to handle this case
	This will require writing a crude performance module, etc.
	(This looks like a job for MRS!  or maybe RLL? or EMYCIN?)

Intellectual difficulties:
(What questions am I just beginning to address?)

As mentioned above, there are several issues which arise, even in this simple
example, within this restricted application of analogy.

*	Initial state of pupil
	(not too literate, nor too ignorant)
*	Pupil's rep'n important -- can make analogy trivial, or interesting
*	Language for expressing "A is like B, except...."
*	Alterring "known" facts - eg rearrange domain skeleton

There is also a major meta-level issue to be resolved:
How does one demonstrate that the expert system now knows a new fact, and
can use it appropriately?
The real issue is how to ask the question -- and whether the question
somehow encodes the desired answer.
(This is, of course, a general problem for learning systems in general.)
	<con't>
I will be designing an interactive analogy-understanding module,
which will be used to expand a growing KB of domain facts.
That initial KB must be rather complete -- having many things
to use as vehicle.  (But not so much that this use of an analogy is silly.)

We will say the system "understands" the analogy when it can use the
topic appropriately.  
(E.g. the system "understands" the M-F command when it uses this command
whenever it wants to move forward a word, and only in such situations.)

-----
Position in Analogy-Space
(See "What's in an Analogy" paper.)

Similarity metaphors (or proportional -- but NOT familial)
Use of the analogy, NOT its generation.
Deductive -- when only a conjecture, it will be examined interactively.
Linguistic (not rep'n)

Pretty much at Instance level --
   o	specificity can vary, but usually at the most precise level
   o	it will end up applying to new single commands, rather than
	classes of commands
	(although they may be communicated in that more generic manner)

Cases will be "closed" -- well definnd single use, and then discardable
Obvious
Refined
IntRAfield -- only from other things pertanent to editors...

Interactive
-----
Given input of the form "X is like Y because α",
this system will basically do a SOPHISTICATED copy and edit:
The smarts will come from deciding what to carry over, and how.

Hence the issues include
1) What features should be
	transfered, guaranteed
	transfered, with only a Y/N question 
		(where Yes is expected, and No requires other work)
	transfered, with value only suggested
	not even considered
2) the value of the feature may be
	simply copied from vehicle
	modified "guaranteed"
	modified suggestively
	restricted to a small set
		<Overview of Thesis Proposal>
∂TO shortliffe@sumex, csd.lenat@score/cc, csd.genesereth@score 16:09 28-June-82
∂TO csd.dietterich@score/su (Copy of Proposal sent to Shortliffe) 14:41 2-Jul-82
∂TO darden@sumex/su Summary  12:38 12-Jul-82
∂TO schooley@rutgers 17:14 20-Jul-82
∂TO tw 11:46 14-Sept  [with message on page 11]
<Overview of Thesis Proposal>
Terry -

This is a copy of the material I mailed to Ted Shortliffe recently;
it is serving as my most up to date thesis proposal.
My next message will outline particular places where I would especially
value your comments and insights.
	Russ

------
I am currently investigating how analogy may be used to facilitate
Knowledge Acquisition.  The goal is a module which will allow the domain
expert to state that a new domain object or set of objects are analogous
to some known object(s).

For example, it will permit a medical expert to use statements like
  (*)  "Viral-meningitis is like Bacterial-meningitis,
	except it is caused by a virus."
to describe Viral Meningitis.  From this, we (and hence any sophisticated
system) should be able to conjecture that this new item,
viral meningitis,
	is a disease, 
	which is caused by a virus, 
	has symptoms which closely resemble those of bacterial meningitis, 
	   (perhaps even specifying in what ways they are alike and different)
	but whose etiology is totally different,
	and whose treatment should be quite distinct.

This summary will walk through this simple example, to illustrate the type
of operations this analogizing module must be able to perform, and where
research time and effort must be channeled.  The next subsections will
sketch how the analogizer will be able to reach these conclusions,
first outlining the analogizing process itself, and then instantiating
these steps using this example.  We will next expand and "correct" many of
the simplifications found in this quick first pass.  It will be clear that
the analogizing program must have access to a great many different types
of facts; many of these are enumerated in the next part.  We next discuss
the benefits stemming from both this module itself, and from this line of
research.  The concluding remarks indicate where the work is now, and
what some future directions might be.  This is followed by an appendix
which discusses reformulation.

<<Meta note: please forgive the technical inaccuracies filling this short
 synopsis.  The goal is to present an idea of what the analogizer should be
 able to do, not to differentiate different forms of meningitis.>>

! ---Overview of Analogizing Process---

For this example to work, the existant MedicalKB must already know a lot
about bacterial meningitis.  In particular, it must know that bacterial
meningitis is a certain kind of disease, with a particular etiology, set
of symptoms and treatments.  Our goal is to derive facts and conjectures
about viral meningitis, based on those bacterial meningitis assertions.
(Stated another way, we are creating a new unit for Viral-meningitis by
"Copy and Edit"ing the Bacterial-meningitis unit.  This involves
discerning which of the Bacterial-meningitis slots are appropriate for
this neo-natal Viral-meningitis unit; and then what values should fill
these slots.  One might, for example, 
(i) simply copy the value, as it stands;
(ii) perform a simple lexical substitution first; 
(iii) perform some elaborate "mutatis mutandis" modification, based
	directly on some first principles of the fields, etc.)

The basic procedure is an incremental "generate and test".  Various
"suggestive" heuristics will propose hypotheses about this
Viral-meningitis.  Other rules will then examine these proposals, pruning
those which are contradictory (or just very unlikely).  Those conjectures
which are accepted are recorded, together with a body of reinforcing (and
negating) justifications.  This propose-and-verify-cycle will continue
until no more generating rules are triggered.

Three quick points:  
1. This overall process will be user-interactive.  That is, any rule may
call upon the user to answer some question which is outside the expertise
of the analogizer or the current MedicalKB.
2. A rule may declare that some earlier assertion is faulty, and cause it,
and all of its effects, to be thrown out.  This will require some form of
Reason Maintenance System, a la [Doyle].)
3. While most users will probably simply use the rules supplied,
he does have the option of modifying them to conform to his desired sense
of analogy.

! ---Example Itself---

Enough overhead; onto the actual conjectures.  How did we know that
Viral-meningitis is a disease?  (Realize that stating that 
       "This sponge is like meningitis,
	in that both have an excess storage of fluid."
does not imply that "this sponge" is a disease.)  Of course we still don't
really know that this is true.  It is a quite plausible conjecture,
though, as we do know that viruses cause diseases, and (*) stated that
Viral-meningitis was caused by a virus.  Such "converse" statements are
viewed as reinforcements of some idea, not as proofs.  (E.g., a virus can
cause a contamination of an otherwise pure culture, or ...)

But why did we even consider asking whether Viral-menigitus was a disease?
This was done at the behest of the general analogizing heuristic:  
	IF the user asserts that "X is like Y", 
	THEN consider setting X:IsA to the same value as Y:IsA.  
That is, we will see if this conjecture, 
(regarding the classes to which Viral Meningitis belongs,)
is consistent with other facts and conjectures about this new concept.

(Two digressions:  
1. One of the most powerful arguments "justifying" this heuristic is that
this IsA classification is often based on the obvious perceived
similarities, on which most analogies are also based.
2. Many other analogizing system insist that the analogues both belong to
the same class -- i.e. share a common IsA value.  We will show later (in
Reformulation part) why this is a serious limitation, and how this system
avoids this constraint.
...but now back to the plot...)

Having established that these two analogues are both diseases, we next
consider what it means for two diseases to be considered similar.  A
medical-domain-specific heuristic states that two diseases are similar if
they manifest similar symptoms, and possibly have similar causes.  Finding
that the name "Viral-menigitus" is similar to "Bacterial-menigitus"
reinforces the conjecture that they should share similar symptoms.
(Afterall, these two diseases may have been named long before anyone
understood the organisms responsible.)  [This "similar name check"
heuristic is also specific to this medical domain.]  As we've been told
their respective causes are different, we know to rule out the "similar
causes" conjecture.@FOOT<Of course another MD might only consider two
diseases to be similar if they are caused by the same organism.  Such an
expert would be able to enter and use this rule, in leiu of the "similar
diseases have similar symptoms" heuristic discussed above.  Of course
this would mean this KA module would have a harder time understanding 
this particular (*) analogy.)

Are the two sets of symptoms actually identical?  Maybe -- realize we do
not have enough information to determine this yet.  We can, however,
simply ask the nearby domain expert.  
@FOOT<This question itself might be ill-formed, as we are really comparing
two CLASSes of diseases, not two single diseases.  It is quite possible
that one member of each class will share identical symptoms, while other
members of each class will not have such correspondents.>

The fact given in the initial analogy, (*), that these two diseases have
different causes means that their respective etiologies will be 
different -- although the similarity of the symptoms places some
constraints on how diverse the etiologies can be.  The ontogeny of the
different organisms, likewise, must satisfy some connecting constraints.
[This reasoning will be based on several things.  It requires, first, a
basic understanding of some medical "first principles"; here, of the
distinction between bacteria and viruses.  In addition, the relation of
cause to etiology must be known, etc.]

Finally, the desired treatments may be completely different -- clearly
antibiotics (which may have some effect on the first bacterial disease)
will be useless for the second viral form.  [This again derives from a
combination of general facts about etiology -- that different causes imply
different end results -- and from basic knowledge of bacteria and
viruses.]

! ---Other Points---

End of the scenario-overview.  There are still many second-order issues
which were glossed over, which must be resolved before this process can be
implemented.  All of the operations mentioned dealt with slots -- either
determining that a given slot was relevant for a particular unit, or
finding a value for a slot.  This is a simplification in two ways.  First,
we will really be concerned with general N-ary relations, rather than the
intrinsically binary slots.  Second, there will be other operations which
will only place a restriction on the arguments of a proposition, but still
not fully specify these values.  (E.g. we may insist that the value of x
in (IsA Analogue2 x) be a member of some set, or that it NOT be some
value, etc.)  It is still safe to say that each operation of the
analogizer will attempt to more completely specify some fact about the new
analogue.

The next point deals with the order of those operations -- which
conjectures to propose first, and which later.  How, for example, did we
know to first determine Viral-meningitis:IsA?  The answer is common sense,
encoded as rule-ordering heuristics.  (The "Do IsA first" heuristic is
easy to justify:  this "is a particular kind of" relation provides a good
discriminant for subsequent facts; the conjectured value to use is easy to
compute -- i.e. it is usually the same as the IsA of the other analogue;
etc.)

The third "nuance" is a major issue, one which seperates this research
from that of other analogy programs:  this program will be able to
"reformulate" the vehicle
@FOOT<This vehicle/topic/ground terminology comes from [Paivio].>
if necessary; and then use THESE newly generated
features for the analogy -- that is, the analogizer will map these
features over to the other analogue.  In these cases, the analogizer will
first find a different description of the first analogue, one in which its
relation to the new concept is more apparent.  A concluding appendix will
better define this term "reformulation", and provide some examples
justifying why it is needed.

! ---Prerequisite KBs---

As we saw throughout the example above, a lot of knowledge, about various
things, is required to reach these obvious conclusions.  We had to employ
facts particular to this medical domain, (including pharmacological facts,
knowledge of infections in general, [e.g. diseases are considered similar
if they exhibit the same "behaviour" (reinforced by naming convention)],)
as well as facts about analogies in general, observations about salience,
etc..  In addition, we needed to include many "common sense" notions --
including a general understanding of causality (e.g. Treatment should be
related to Cause); and a variety of general heuristics -- including the
"Copy IsA, whenever possible, as soon as possible" rule.  How to encode
these diverse facts is a major research challenge.

! ---Usefulness---

There are several strong justifications for this work.  It will contribute
both to Expert System technology in particular, and to AI in general.
Reasons (1) and (2) below indicate why we feel that this elaborate
automated "copy and edit" process, in and of itself, will facilitate the
construction of superior KBs, faster.  (These claims are, of course,
currently just conjectures.  They will be empirically tested when this
module is up and running.)  This is, however, only the "straight-forward"
component of the a more exciting program(me).  Reason (3) discusses our
use of reformulation, which we feel is a contribution to AI in general.

(1) The resultant KB will be more accurate.  
By automating much of the KA process, the domain expert is spared the
arduous and exacting task of actually inputting each specific fact about
each new object.  Not only will this module help when fleshing out
skeletons during the 2nd KA stage, (see [Bennett: Sacon],) it could also provide
a Tieresias-like ([Davis]) verification, to insure that like objects have similar
features, with similar values.  (Here the check can exceed Tieresias's
purely syntactic check, using some of its domain knowledge to determine,
for example, just how the values of a given slot for two different units
should compare...)  [Actually, this verification would be a (hopefully)
straightforward embellishment to the proposed module.]

(2) The KB will be generated and refined faster.  
This is because the language used for the interaction is more accomodating:  
a) It is more natural to the expert.  
    Pf: Consider how experts communicate amongst themselves -- "this patient
    just like that one", or "these chemicals are just like those", or "think
    of this as water flow", ...
b) It is more succinct -- relatively few symbols will be used to encode many
    assertions.
    Pf: Claiming "A is like B" really "expands" into a host of assignments of
    facts about A.  (Of course storing the declarations which are used to
    translate from the statement of the analogy to those assignments may be
    non-trivial.)

(3) This module will be able to reformulate the analogues as a first step
in finding the relevant analogy.  This may involve simply high-lighting
one particular perspective (or feature-space) of the vechicle, or the more
complex task of deriving a new space of features.  (The appendix will
explain this use of reformulation -- telling what we mean by this term,
and why we consider it essential.)

! ---Related (dare I say analogous?) future work---

The ability to comprehend a given analogy, even in these rather
constrained situations, seems a prerequisite for many of the other uses of
analogy.  Given a module capable of this behaviour, one could imagine
using it to use intERfield connections -- e.g.  
	"A text editor is like a Secretary, except ...", or
	"Computer diagnosis resembles Human diagnosis in that ...",
etc.

The task of finding the best analogue (that is, finding the case which
most resembles some current situation,) would surely use the capability
of understanding how two particular situations are similar, which is just
what this proposed module would provide.  (The expert who works from cases,
who examines his 50 - 100K friends (see [Simon]), searching for the one 
which is closest to his current case, is using just this ability.)

Consider how one might use analogy for teaching:  One has to find to find
the desired analogue-pairs to present, (which is basically the "find best
analogue" task described above,) together with a description of how they
are (and are not) related, which is closely related the KA task discussed
here.  The flip-side of teaching, learning, is precisely the KA task.

! ---Conclusion---

This sketch hints at the numerous advantages of using analogy during
Knowledge Acquisition.  To make this point (and my thesis) more concrete,
I clearly need is a body of real examples.  Trying to be my own Domain
Expert, I originally chose the (more familiar to me) domain of editor
commands as principle domain.  This has the major drawback that it is
sufficiently artificial and artifactual that any derived intrafield
analogy felt both obvious and un-interesting.

This is why I would like to "connect up" with you: [Ted Shortliffe]
to get one or more realistic KA scenarios, each one reflecting a real 
(hopefully medical) situation, (which, who knows, may even help the domain
expert it was designed to benefit...)  This is what I would like to discuss with
you, at your convenience.

*********
! ---Appendix: More on Reformulation---

Unlike other analogizing programs, this system does NOT depend on one
particular representation for the analogues.  It can, instead, select the
most apt perspective, or even generate a new feature space if necessary.
The features the topic will "inherit" will be from that feature-set.
This appendix will answer the questions: Is this reformulation step useful?  
If so, why have prior analogizing programs been able to use a single
representation, seemingly able to completely avoid this problem?

One very seductive property of analogies is that any given analogy is
obvious, in retrospect.  Once one has described how the analogues A and B
are similar (in general because they are both Ys) any feature which you
find both A and B share will seem obvious -- of course P(x) holds for both A
and B; it holds for all members of Y!

Unfortunately, one does NOT always start with this crisp Y class; instead,
one may be forced to infer it from the examples.  This is one of the real
challenges of this work (and its major AI contribution) -- determining how
to glean from the vehicle, together with a brief description of the
desired analogy, the space of relevant facts to map from this analogue
over to the topic.

We need a different example to demonstrate the usefulness of this
reformulation step.  Consider first the obvious connection between blood
and lymph -- as each IsA circulating bodily fluid, it is not surprising to
find many correlations.  Now imagine that someone said that the endocrine
network is similar to the blood system, except it uses "message carrying"
hormones rather than indistinguishable mass-type blood.

This endocrine system is clearly NOT a circulating bodily fluid.  It does,
however, share many properties with such systems.  For example, a pathway
may be blocked, preventing transference of the material.  Or there maybe
some feedback loops.  And, given such a topology, there are a host of
problems which might arise.  (E.g. some "Stop Sending" signal might be
lost if the return part of the feedback loop was either open or blocked.)
The reason for these commonalities should be apparent:  in both cases some
material is travelling from one location to another.  Hence any of the
properties associated with "material flow" should pertain to both of these
systems.  But what if the current system lacks this essential category?

We would still want the analogizer to consider endocrine-related illnesses
which resemble blood-blockage, or open-loops.  [Sorry I don't know the
names for these ailments.]  After analyzing this situation, we may want
to reconfigure the KB to actually have a Material-Flow class, which is a
superset of "circulating bodily fluids", and the class to which "endocrine
system" belongs.  Thenafter anything which IsA MaterialFlow would inherit
all of those facts common to such systems -- including this list of
possible illness causes.

(We might later consider connecting our Neurological Networks (or even
electrical curcuits in general) with that endocrine system.  They are both
instances of elaborate circuits, and, as such, subject to certain classes
of disruptions.)

As mentioned above, it is only in aftersight that the need for such
categories became obvious -- it is silly to think that we might have
known this, and every other type of relevant category, beforehand.  
Solving this challenge -- of how to find such commonalities when they
are needed, especially when they are NOT explicit in the representation,
but rather have to be teased out -- is a major reseach effort.

	Responses to Summary
∂TO CSD.GENESERETH@SCORE  11AM 30-June
No, no, no
    ∂29-Jun-82  1652        <CSD.GENESERETH at SU-SCORE>    Re: <Overview of Thesis Proposal> 
    I got your message.  Seems like a lot of words.
    mrg

You're totally misinterpreting it!  When printed out, in the standard
Helvetica font, and held in front of a mirror, with the sun over your
left shoulder, it appears as a PICTURE of a Buddhist monk, meditating under
a zuchinni shrub, in a winter snow; OBVIOUSLY!
Sometimes I wonder about you, Mike...

∂30-Jun-82  2226	<Shortliffe at SUMEX-AIM> 	Re: <Overview of Thesis Proposal>
cc: csd.lenat at SU-SCORE, csd.genesereth at SU-SCORE

Russ,
	Thanks for sending along a copy of your thesis proposal.  Will look
it over and get back to you.
	Regards,
	   Ted
Etiology
	Different Causes require Different Treatments

Medical
   Each disease has a
	Etiology (causes), Sign/Symptoms, Treatment
	 [?other connections: pre-disposition, prevention, ...]
   Similar diseases have similar symptoms
   Different organisms require different treatments
   Bacteria (but not viruseq) cAn be killed by AntiBioticq

General
   Copy IsA whenever possible

----
Meta
   Determine I`'∧ACfAM←←\A¬fAa←MgSEY∀~∀→%kY∃b~∀xq'Si@.S'?sQ↓α∨O3↔9↓∀	β'Mεc'/∃∧⊃1β≠⎇⊃βK↔∂≠?9α~⊃1βπv!β3?'→β'Mε[;?←rβπ∨-!α	0hP'≠≥IBεNdλf∞∨N4ε∞⊗|VB∧
dπcph!Q"α¬MxfNvG$∧T≤<∩αjQQ M≡↑@∧T≤<∩¬Zλ'$O≡∃Dε∞vD
F∞h≥~
≡h→0≤≤2y4fYw:0v∧¬
	  [peRhaps using a @I%H≠↔⊗+;Aβ&C↔?KJaα∞≡u~&∩⊗∃`⊂hPβ"H∧λ≠h∩.≤(→@∀\αst
  SI@5SYCdαβ∪'O,∧↔∞∞4	ε∂6T
6Nn≥H↔απ?→Wπε⎇↑0hR∧
6Nnα;⊂.⊂1pz\pp∪ @1KCHAQ↑AgSαk'3π⊂∧πNY8=
\αs:9CE⊂⊂*\p¬ antibiOpics t`≡AiIKChAα#'O⊗∧≡6/~0λ.↑y1⊂_<P∀1Yy:0t[∀P "acteria 4R↓α∪'≤+πO↔~βπK∃∧≠πWN(∧Bε↔∀λFO≡Xλ<lUα`sr[:9WεB⊂⊂"4\p¬as%-AgeNts i@9GYkI∀A¬CGQKeCB↓C]HAYSekgα+@_h!⊃PTn]m⊗v>≡NW4~<h∀_s⊂⊂\yP7`& diseases,
α↓iNdicate` by af @%]MYC5CiS←8A@∨→∧εFF*
\VvNβYy.∀A"C!*≥{h∞N∧x"`3 kf @Q`↔π&k↔;QPh %!λ@∩∧∞LN&/∨4λ

(≤}-↑≥≠s.4λεV@ e*g.↓QKgg∃\AaC%\∩∧∩ dRAβ⊃IeKgβ→βS#*β∂πW≡1βπ>+;Q↓hiβ∃;:qβ/;|≠ ~π↑∧ε⊗∞>LWεN≥DεNvl\7&N⎇aP@h!Q"jjQQ$ε∞>LW⊗N≥ETn.m≥f>OM≡2∧O<⊂∧&O<Xλ.<!"C!*Z<X-E393M≥Yz=
≡c"@↓J≤<⊃.P7s⊂→0qz9K⊂:yrY⊂;t2[⊂22yXy4q4[3P0wλ7q5"XzεE_JP(:y≤7yrW\0πle --¬
2) Functionality
↓I/M behaviour, (dynamic) states
	OperatiOns
3) @∪]QKeMC1f~∀∪
←[a←αs↔;S~aα7π&+@⊗N≥EB¬∨N.V∨'↑,RαF≥nF/⊗=xMl8⎇→,MY<|l↑h#"FE(⊂{≡|z1M≤x=~-⎇C"M%∀⊂πb4→y⊂:4~w3yPVP7g≥5srw≡T⊂44\z7y<K⊂2s&ects, ...
-----
αI↓9giC]
JtAα↓H'3Ls∃β∂∞∪';↔w 4)EJαC@/(	w∞
}-vf*¬UPhR∧∧ααπMtεF␈↑8Rε6⎇LF/↔1Q"αα∧∧ααα∞=vn∂M≥V/~∞<V∨/,YGJλ≥<n\9≠⊗$
|Yx-m>Y9¬D_;∃l∨<h≤≡Y~5
≥{Y1¬⊃"LB$λ];XnM;{X-M=~#!$λλλ∧	+sh,:_=M≥⎇<NDπc"H∧∧λλ→∂≥X;:,4≤⎇_.L<nH<8Z;L]]λ∪,∨(_Y$
≠xzl\∞h_m⎇]→;NNh≠8/∀_Y(∞=|]→,Gc"B
≡λ≠8/∀_Y(n;≠∞d∞~→(
∃=~λNX=y.∧≠8>$Y(∪n;N`
≡λ≠8/∀_Y(
}=λ∪lD≤≠_,<.hEeC"H∧∧λλ∪n<X=
≥{\nD	≠xzd
=λ∞=|]λ
≡≤h_m⎇]→;NNkλEeH∂⊂.D≠→8.>λ≠{LT≤→<D∞⎇_=WC"Le∀⊂;]↑[X;∞1"Hλ∧∧λ⊂{m↑≠{Y-n≤nHλNX=y..kλ
∞l<]~,<;≠≡$∞⎇_8m<9
$[{→↑\kλπL{{]]]≤h
|H→SmL→<OAQB:;LM8y<d¬≠{Y$∞≠h_$[{→↑J#"D∧λλλ	\=→<M≤;∞H	\=_;∧∞⎇≤],>≥<Y%D≤_<↑H→[mL→<\eD≤_<↑K|≠≡⎇~8d[{→↑H_{mn→;]∞1"Hλ∧∧λ∀⎇∞.8⎇≥.,.H∀nL8zy,D⊃≤X.|<\k∧
≠⎇<l\λ~;D(→\L≥9+λ
≡h_(m;~;Lt_x8M≥Y;]¬a"B1,≤zλ→∞,=y<D
_<h∀λ[~.>λH≠ld_{{NL;]≤eD≤_<NM=~;ml9λ~-n≠h→M⎇→→<N5λKEa"M
$λ{_<n=9Z8l≡~;{AQB2<l∀∀~≡.=8x;∧
xZY,>λ≥.>8;≠∂∀→[u-lλ~;D;H≠llZ8y%D≠y]]H~0↔λ3y7z\9VεEαQ897XryyrY⊃⊂1<H7s34XrV{w\5ry9H∀9rq\2z0y~ryV⊂≠s34qYP1v2\4qpvλ;wy5Yy9V⊂↔↔∀FB∧VVVH#7v2→y9P1[w:0t[⊂4w3≠y6pz~ww⊗⊂→w1wr→r⊂4wλ;wy2≤P7w⊂≤0x2y⊂↔↔↔βEεE~JP'z4→y⊂:4~w3yPβE⊂⊂⊂λ≡1ww_rx:⊂≠s⊂#4[4w3P_pq4w→w:∨εB∧b2yZsw2rλ1<P∨K⊂4w⊂←←←Vλ37y⊂∂←←P⊗λ4w⊂:~2P1g]w:9<H∨←←Vλ4w⊂2↑1t0w→rP37\⊂∩∨DU42y2H0y2P∂P4w⊂≥yrP:≠r0tFB⊂⊂⊂⊂∂:<x4Xpv⊂3~v4w3H1pq4[2w:∨βE∧`{→y0srH64s2\x0w⊂~yP∨P≡rpy9NP2:y~w3P;Z4qt⊂≥4vrP~0{4w→P∨P7]w2y9CE⊂⊂⊂λ≡9rzλ7s⊂3~v4w3H1pq4[2w:9OεE∧j~es of ...
    <specific filing cabinent>
	"Did you hear the joke about the traveling FC who ..."
	The Smithsonian houses ...
    -- amusing/relevant anecdotes --
	Pol-glycote finish caused cancer in teenage rodents, on Thursdays, ...
Consider how analogies might be used by people wrt computer programs.

(1) Analyze/understand program A, based on knowledge about B, and connection
	of A to B.

(2) Generate new code, by analogy with existing code
	(a) Create a new program
	(b) Augment an existing program

(3) Modify existing code, in running/errorful program
[Note similar types of bugs, ... in different programs]

(4) Device a macro, capable...
--------
Scenarios:
   o	I know about MAPCAR, and am told EVERY is similar, but ...
	   Deduce what EVERY does.
   o    Given spec for EVERY, copy and edit MAPCAR to perform this function.
	   (or MAPC, or MAPLIST, ...)
   o	Concoct the macro which is used to implement these mapping functions   
   o	Optimize code -- same I/O, but faster or less space (e.g. DMAPCAR)
   o	Given PR-STASH, generate PL-STASH, which works with Property lists,
	   rather than the hash table PR-STASH used.
   o	Figure how to write PL-UNSTASH, 
	   given relation of PR-STASH to PR-UNSTASH, & PL-STASH.
   o	Given MACLISP code for function F, rewrite F in InterLisp.
		or Pascal, or FORTRAN, SETL, APL, ...
   o	Change the data structure
	    -- e.g. deal with linked lists, not bit vectors
   o	Change the type of objects program X deals with 
	    (not just their representation)
	    Given UNION, and def'n of SET and LIST, 
		write (various flavors of) APPEND

-------
Why this domain -- of programming?
* one has "complete" information -- 
	hence if one representation doesn't work, can produce another one
	(starting from that "primitive" code) -- `reformulation'
* perhaps will be used to concoct a new representation -- eg programs
	which use certain tricks, or written by Fred (who likes capital
	letters)
	[is this exactly "learning by ostention"?]

-------
How can Program A be like Program B?
* wrt I/O behavior
   o (abstract) functionality -- e.g. both "sort"
   o Data structures involved -- eg linked list, not bit string
   o "interpretation of data" -- eg sets vs lists
   o Timing - both absolute CPU or real time, or assymptotic
* wrt structure
   o procedure calling sequences -- eg CAR recursive, ...
   o details of code -- eg variable names
	Nuances of coding style of
		Author, Author's school, ...
	    (e.g. DBL: Long variable names, many globalvars)
   o Language used for implementation
   o Abstract description of code
	"tricks used" -- i.e. version space, or path compression
	same task -- e.g. learning
∂TO tw 12:01 14-Sept-82
Specific Issues
Terry -

Below is a list of specific questions I have about this project,
which I would particularly like to discuss.  I would, of course, value
any and all other comments/ suggestions/ proposals you could volunteer.
Thank you again for your time and energy;  I look forward to meeting with
you at noon, 21/Sept,
	Russ

-----
(1) General comments on this project:
	Is this thesis-worthy and relevant?
	Do you think it will be useful?
	Is it doable?  If not, on what subset should I concentrate?
	...

(2) I never explicitly stated the model of analogy I was using:
I think of an analogy problem as a statement of the form 
"A is like B within constaint C".  (I even have a partial catalogue of such
constraint clauses.)
The "goal of the analogy" is to enhance/complete this description,
which is achieved by finding additional correspondents between A and B, 
(thereby expanding this constraint C).
I'm very curious on your comments wrt this model;
e.g. its generality, or constraints, and issues of implementation.
That point leads to

(3) Linguistic aspects of this task,
in particular how to handle issues like context and initiative.
(... based on the observation that it is often possible to omit this
"within constraint C" clause; as it can be inferred from context...)

I have been totally ignoring these issues, viewing them as frills which can
be tacked on at the end.  Do you think this view is wrong?  Should I, instead,
be concentrating on these issues?  Are they really part-and-parcel of this
analogy task?
...